For large BigFix deployments, the factor that will influence performance the most is the speed and performance of the disk system for the database and server components. This information is specific to the BFEnterprise SQL Database and Transaction log files for the Tivoil Endpoint Manager application for all versions 8.2 and less. BESReporting, BFInventory and other TEM related databses do not follow the "many small writes" architecture and are therefore more SAN friendly.

 

Disk Performance - IOPS, Throughput, Latency

Agents report their statuses often and BigFix Server will insert the agents results into the database. This leads to a pattern of disk writes where there are many small disk writes (rather than large disk writes that are typical of some other disk-intensive applications).

Due to disk behavior, good BigFix performance depends much more on low latency disks rather than high throughput disks!

BigFix often sees poor disk performance for SAN (even high quality / high performing SANs) because SANs typically have high latency. Direct attached storage usually performs much better than SANs because the latency is often much lower (see picture below).

 

Here are example latencies and their expected performance characteristics:

Latency (ms)	Performance
50+	Really Bad
20	Busy
10	Average
1	Great
.1 to 1	Fantastic
<.05	Best Recorded

 

To test your disk performance, BigFix recommends using IOMeter (http://www.iometer.org/).

 

Recommended BigFix Array Configurations

Expected Performance	RAID Controllers	RAID Array 1 (internal)	RAID Array 2 (internal)	RAID Array 3 (external)	RAID Array 4 (external)
OK	Single RAID controller with two array slots	RAID 5 (3+ Disks) OS, BigFix Application, SQL Server Application	RAID 10 (8+ Disks) Database, Transaction Logs	n/a	n/a
Better	Two RAID controllers	RAID 5 (3+ Disks) OS, BigFix Application, SQL Server Application	n/a	RAID 10 (8+ Disks) Database, Transaction Logs	n/a
High	Two RAID controllers with two array slots	RAID 5 (3+ Disks) OS, BigFix Application, SQL Server Application	n/a	RAID 10 (4-8+ Disks) Database	RAID 10 (4-8+ Disks) Transaction Logs
Optimal High	Two RAID controllers with two array slots	RAID 5 (3+ Disks) or RAID1 (2 Disks) OS	RAID 10 (4+ Disks) BigFix Application, SQL Server Application	RAID 10 (8+ Disks) Database	RAID 10 (8+ Disks) Transaction Logs

 

RAID Information Pertaining to BigFix

• Minimum Number of Drives: 2
• Strengths: Very high performance, very high data protection, very minimal penalty on write performance.
• Weaknesses: High redundancy cost overhead, all data duplicated means you get half the storage available in disks.

• Minimum Number of Drives: 3
• Strengths: Best cost/performance for transaction-oriented networks; very high performance, very high data protection, supports multiple simultaneous reads and writes.
• Weaknesses: Write performance is slower than RAID 0 or RAID 1.

• Minimum Number of Drives: 4
• Strength: Highest performance, highest data protection (can tolerate multiple drive failures).
• Weaknesses: High redundancy cost overhead, duplicated data halves available storage, requires at least 4 drives.

1. The only types of RAID it makes sense for use with BigFix are: RAID 1, RAID 5 and RAID 10. The only reason you would use RAID 1 is because you don't have enough disks or you are using it for the OS array. The only reason to use RAID 5 over RAID 10 is because you don't have enough disks.
2. RAID 1 - Disk Mirroring
3. RAID 5 - Block-level data striping with distributed parity
4. RAID 10 - Combination of RAID 0 (data striping) and RAID 1 (mirroring)

Guidelines

1. Smaller/faster disks are best. BigFix doesn't use a lot of disk space so we are better of maximizing disk speeds and throughput over volume.
2. SAS/SATA Drives and Raid Controllers are better then SCSI.
3. Prefer 2.5in drives at 10K or 15K RPM over 3.5 in drives at 15K RPM. Smaller form factor reduces seek times. Solid State Drives or FusionIO cards are very good for the core TEM database.
4. RAID 10 provides best performance (read/write throughput and seek times). We would expect 8+ in each array (16+ total) in the high end servers.
5. RAID 5 typically used on OS for fault tolerance and good performance.
6. RAID 5 occasionally used instead of RAID 10 on SQL arrays but we prefer RAID 10 because it is faster. Notice that RAID 5 is slow on writing so it would not be good to use with a database array that is heavy on writing.
7. You can partition the RAID arrays into logical partitions which are smaller to maximize seek times. That is, if your array of small fast disks provides 120 GB but your database on the array only uses about 20 GB you could separate the array into 2 logical partitions of 60 GB (or 80/40) each and not use the second partition. This forces the database to use only half of the platter and maximizes seek times (disk heads don't ever need to track to the unused partition).
8. Separating the transaction logs helps maximize the database throughput since each SQL transaction requires a write to the transaction logs, then a write to the database for the transaction itself and finally a commit to the transaction logs.
9. Typically RAID cache ratios are set to 50/50 read/write. In some cases it may make sense to try something more granular like 25/75 read/write for a database which is doing a lot of writing but not much reading (i.e. a large deployment with very few BigFix Console operators).